home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / text0319.txt < prev    next >
Encoding:
Text File  |  1992-11-30  |  10.2 KB  |  206 lines

  1. At the end are some condensed thoughts about directions for merging  
  2. applications.
  3.  
  4. |  Date: Tue, 03 Nov 92 14:08:54 CST
  5. |  From: Dan Connolly <connolly@pixel.convex.com>
  6. |  
  7.  
  8. |  >> Dan:
  9. |  >>     Should WAIS clients grok URLs? I don't see any need.  Similarly for
  10. |  >>     gopher clients.
  11. |  > Tim:
  12. |  >    If you want to keep the WAIS and Gopher worlds totally distinct,
  13. |  >    then no.  But who wants to have all these separate clients around?
  14. |  >    Noone: that is the big user puzzlement with NIR now -- why so
  15. |  >    many systems when they all do the same thing? The first step
  16. |  >    toward merging existing systems, *AND* allowing for future systems
  17. |  >    smarter than the ones we have thought of now, is the URL.
  18. |  Dan:
  19. |  Well, you took the bait, but you didn't run with it very far.
  20. |  "The first step towards merging..." -- so you _do_ have a deployment
  21. |  strategy in mind. You just didn't put it in the RFC.
  22.  
  23. (Can you punt bait?)
  24.  
  25. The RFC is to define one piece of the whole. It is most important to
  26. keep the peices distinct, or the whole thing will be too rigid. I suppose we  
  27. could propose "All the world should use W3 and we should all discuss what W3  
  28. should be like next" but that would never fly. We see that URLs are essential  
  29. to allow communication between applications and different environments and for  
  30. the introduction of new namespaces.
  31.  
  32. |  I'd like to see more motivation in the form of a strategy or at
  33. |  least a vision for how this whole thing comes together. I'm trying
  34. |  to piece it together myself, but I'm not having much luck.
  35.  
  36. That may be because the bits aren't available.  Like a global solid reliable
  37. directory system, for example, and a global payment mechanism or two, and  
  38. athentication systems to support it.  These just aren't globally deployed yet  
  39. so we will have to wait for them and then plug them in.  What we do have is the  
  40. internet, TCP/IP and DNS and we have to put hooks for everything else.
  41.  
  42. |  For example, I really don't see why different protocols should
  43. |  share addressing schemes, or why the sheme:path syntax should
  44. |  go any further than the WWW project.
  45.  
  46. It is the scheme:path syntax which allows the bridge. It need not be used
  47. in closed applications, but in open applications it is needed. W3 will be able
  48. to incrementally move to new name spaces. If other apps don't, too bad.
  49. But I think they do.
  50.  
  51. |  >    Yes. Certainly a useful aspect of URLs. But not the only.
  52. |  >    What about the URL pasteboard type? To allow "cut reference"
  53. |  >    and "paste link" to work between applications?
  54. |  
  55.  
  56. |  I've been trying to work out a design for this, and URLs don't seem
  57. |  to help much. If you copy a WAIS URL and paste it into another
  58. |  client, that client has to grok WAIS protocol in order to use it.
  59.  
  60. Or have access to any WAIS engine. There are 100 ways of keeping a
  61. register for a user for what applications can handle what kinds of
  62. namespace.  This will probably be something which is more difficult
  63. to standardize on, as NeXT and Windows and Motif etc will all have different  
  64. schemes for registering application capabilities, and different  
  65. inter-application messaging techniques.
  66.  
  67. There is some analogy between capabilities to deal with UDIs and capabilities  
  68. to deal with data formats here ... Mark Litwack (are you there, Mark?)
  69. had a scheme in which the two merged.
  70.  
  71. |  Or it has to use a gateway. If it uses a gateway, it has to translate
  72. |  the WAIS name into something suitable to that gateway, which is
  73. |  something you said you didn't think was practical.
  74.  
  75. I don't think the client has to translate anything necessarily.
  76. The http protocol allows one to send over a URL including the
  77. prefix, which need not be http:.  For a protocol which does not deal
  78. in generic URLs, some translation would be necessary.
  79.  
  80. |  Anyway, if you're
  81. |  going to define a gateway system, then define a gateway system, not
  82. |  just an addressing syntax.
  83.  
  84. The gateway system is a time differential of the set of protocols used.
  85. It will always change to reflect the movements between protocols. I agree
  86. that the HTTP protocol could perhaps have something in the spec to point out  
  87. that the full UDI may be sent to a gateway.
  88.  
  89. |  I'm trying to figure out how URLs complete the picture, but I don't
  90. |  see it.
  91. |  
  92.  
  93.  
  94. There will be a few things in the picture. URLs are the most important next  
  95. step now, a timely requeirement for commonality. That's all. They will not  
  96. solve all the problems.
  97.  
  98. You want a merging strategy. Suppose it is as follows, off the top of my head.
  99.  
  100.               MERGING STRATEGY
  101.  
  102. The metastrategy fro developing strategies is to first, make a model of
  103. a superset of the functionality of the various systems, then design protocols  
  104. to implement them, then make applications which use both old and new. Beware  
  105. that merging all the applications onto one is only one as seen from the user,  
  106. hopefully there would be separately developed products on there with messaging  
  107. between them. 
  108.  
  109.  
  110.     Merging WWW and WAIS and Z39.50:
  111.  
  112. A new HTTP2 protocol is defined, back-compatible with the current one.
  113. It involves sending a request which is a particular format. There are MIME-like  
  114. formats defined for a simple document request, a basic WAIS-like query, and if  
  115. necessary other Z39.50 queries. This means establishing a mapping between the  
  116. Z39.50 parameters and an ASCII internet-mail-like format. We make the set of  
  117. query types as open as the set of document format types and encoding methods,  
  118. and allow for a registery of names like IANA.  The formats acceptable to the  
  119. client are sent with the request [as mail header lines or in the body?].
  120. The query types acceptable to a server are returned by the server when a  
  121. queryable object is referenced.
  122.  
  123. We look at the parameters necessary for this process and add them to the WAIS  
  124. protocol, so that Z39.50++ becomes a binary (and therefore perhaps more  
  125. efficient) version of HTTP2. The binary and telnet-style versions run  
  126. side-by-side, with fairly simple table-driven interfaces. The telnet version  
  127. will be useful becasue of all those perl servers which will be eth leading  
  128. edge.
  129.  
  130.     Merging with SQL:
  131.  
  132. This model will engulf query/retrieve systems, including e.g. SQL queries,
  133. and allow for upgrade for new ideas of remote operations. In fact, the
  134. query type will generalize to a typed set of input parameters for a arbitrary  
  135. operation [method] on a remote object with the given URL, and so in principle  
  136. can access a globally distributed OODB. In order to get a more manipulable  
  137. version of the results of an SQL query or arbitrary OO operation, we will  
  138. probably need a data tagging system [maybe ASN/1 based?] for structured  
  139. [alpha]numeric data such as SQL handles, but this is just another data format,  
  140. not our problem now. The question of converting data formats on parts of  
  141. multipart messages [structures] will be addressed, nothing uinsurmountable. We  
  142. would obviously like to see a mapping from any OOP's identifier space into URL  
  143. space.
  144.  
  145.     Merging with Mail and News:
  146.  
  147. Now look at what we have. The presentation part of the W3 client is just the  
  148. presentation part of MIME, with an added hypertext data class. MIME really  
  149. should have picked HTML instead of text/richtext, but that we can add.
  150. Now we address the intruiging area of the merging of mail, news, and NIR.
  151. The same application must obviously be able to handle all of these, and they  
  152. should all look the same to the user. That is, if you link an article to a list  
  153. of articles, post it to a newsgroup, or mail it to a mailbox, the operation  
  154. (adding message to list of messages) is beasically the same, and should be sen  
  155. as such. Note that MIME has to be augmented with the addition of query type  
  156. registration, there needs to be a format for the summarizing of capabilities  
  157. (mailcap information) in with requests. The mailcap information needs some  
  158. extension. A spinoff is that the HTTP protocol should run over mail too, which  
  159. though excruciatingly slow is neat as a lot of people still use mail servers  
  160. ;-).  This occured to me when implementing
  161. the W3 server.
  162.  
  163. The mechanisms underneath are currently many and varied in order to be optimal  
  164. in the extreme cases of personal messaging, news broadcasting, and archive  
  165. serving. However, as cache coherency protocols are added to HTTP, the functions  
  166. like "give me a list of what is new in the following domain" will approach NNTP  
  167. functions.  Within time it will become a decision made on the fly by the system  
  168. as to whether a document [message, article] is held, sent, or broadcast. So I  
  169. expect the protocols to converge.  An important issue here will be  
  170. charactization of basic operations on sets [maillistarchives, newsgroups,  
  171. directories].  The engines which speak the new combined protocol will have to  
  172. speak the old ones too for back-compatibilty for a few years. This is
  173. a smooth trasnsition strategy. We're not talking about vast librares, just  
  174. supporting SMTP and NNTP and HTTP for a while (they are very similar) as well  
  175. as a superset protocol.
  176.  
  177.     Stargazing
  178.  
  179. What else do we want to merge in?  Name servers of course are just HTTP2
  180. servers which return "forward" results. File systems, I expect, too, will veer  
  181. in the general direction. Alex-like systems will map the retrieval subset onto  
  182. the subset. Maybe soft links could generalise to URLs. Maybe some smart  
  183. manufacturers will allow a soft link to be a URL.  If not, file suffix which  
  184. indicates a query or just .MIME would be enough to indicate that the document  
  185. contains type information and could be a pointer or a query. However, there is  
  186. basic functionality which the file sysyem does not support (That is, anything  
  187. other than open, read write and close: no arbitrary methods here) so we will  
  188. never map everything to fopen(). But by that time we'l all be using our  
  189. favorite OO systems anyway. The exciting part will be to see whether the GUI  
  190. builders will get to the point that the whole OO application can by built  
  191. graphically, bridging the gap between the app builders and real programs (Can  
  192. you imagine progamming in perl with a mouse? in Eiffel?)
  193.  
  194.     Tim
  195.     
  196.  
  197. __________________________________________________________
  198. Tim Berners-Lee                       timbl@info.cern.ch
  199. World Wide Web initiative             (NeXTMail is ok)    
  200. CERN                                  Tel: +41(22)767 3755
  201. 1211 Geneva 23, Switzerland           Fax: +41(22)767 7155
  202.  
  203.  
  204. 
  205.  
  206.